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The DOCSIS (Data-Over-Cable Service Interface Specifications) Device 
Class DHCP (Dynamic Host Configuration Protocol) Relay Agent 
Information Sub-option 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document proposes a new sub-option to the DHCP (Dynamic Host 
Configuration Protocol) Relay Agent Information Option. This new 
sub-option is for use with DOCSIS (Data-Over-Cable Service Interface 
Specifications) cable modems and describes a "device class" to which 
the cable modem belongs. The cable modem signals its device class 
information to the Relay Agent using DOCSIS signaling, and the Relay 
Agent forwards the device class information to the DHCP Server which 
can then make a policy decision based on it. 


1. Introduction 


The "Relay Agent Information" Option is described in [1] and includes 
several Relay Agent Information sub-options. This RFC proposes an 
additional sub-option for use with DOCSIS cable modems. This sub- 
option is added by DHCP relay agents which terminate cable modems. 
The sub-option encodes an identifier of the device class to which the 
cable modem belongs. It is intended for use by DHCP servers to make 
policy decisions based on the device class of the host. 


The motivation for using a Relay Agent Information sub-option, rather 
than a new or existing DHCP option, is the introduction of CPE 


Controlled Cable Modems (CCCMs) [2]. In an implementation of a CCCM, 
the modem firmware controls DOCSIS signaling, but the attached 
computer (CPE) manages other protocol activities -- particularly DHCP 


client message handling. The assumption of this document is that it 
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is better to trust the operation of the CCCM firmware, than to trust 
the operation of CCCM software running on the attached computer 
(e.g., a standard PC). 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as described in RFC 2119 [4]. 


2. DOCSIS Device Class Sub-option 


The DOCSIS RFI specification [3] specifies the Device Class encoding 
within the payload of the Device Class Identification Request (DCI- 
REQ) message. The relay agent MUST pass the Device Class value 
unchanged to the DHCP server. Possible uses of this field include: 


o host endpoint information 

o host hardware capabilities 

o host software capabilities 

o host options information 
DOCSIS defines the Device Class to be a 32-bit field where individual 
bits represent individual attributes of the CM. Bit #0 is the least 


significant bit of the field. Bits are set to 1 to select the 
attributes defined below. 


bit #0 - CPE Controlled Cable Modem (CCCM) 
bits #1-31 - Reserved and set to zero 


The DOCSIS Device Class sub-option is coded as follows: 


SubOpt Len Device Class 
+------ +------ +------ +------ +------ +------ + 
| 4 | 4 |a | a | a | as | 
+------ +------ +------ +------ +------ +------ + 


The DHCP server needs to understand the meaning of this sub-option in 
order to offer different policy options in its reply to the host. 
DHCP servers MAY use the device class for IP and other parameter 
assignment policies for cable modems. 
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3- 


Security Considerations 


Operation of the DHCP Relay Agent Information Option relies on an 
implied trusted relationship between the DHCP relay agent and the 
DHCP server. The discussion of security considerations for the DHCP 
relay agent information option [1] apply to this sub-option as well. 


Operation of the DOCSIS Device Class sub-option relies on an implied 
trusted relationship between the DHCP client (i.e., the cable modem) 
and the DHCP relay agent, through DOCSIS signaling. According to 
DOCSIS specifications [2], the cable modem firmware always controls 
DOCSIS signaling, but cannot control DHCP client message handling 
(e.g., CCCMs). This document assumes that the cable modem firmware 
is trustworthy for DOCSIS signaling information. 


This document introduces a new identifier, the DOCSIS Device Class 
sub-option, that is provided by the relay agent device and is assumed 
to be trusted. Cryptographic or other techniques to authenticate the 
device class are beyond the scope of this document. 


IANA Considerations 

IANA has assigned a value of 4 from the DHCP Relay Agent Sub-options 
space [RFC 3046] for the DOCSIS Device Class sub-option defined in 
section 2. 
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7. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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